Skip to content

Taper leithy#403

Merged
alperaltuntas merged 4 commits into
NCAR:dev/ncarfrom
iangrooms:taper_leithy
Feb 11, 2026
Merged

Taper leithy#403
alperaltuntas merged 4 commits into
NCAR:dev/ncarfrom
iangrooms:taper_leithy

Conversation

@iangrooms
Copy link
Copy Markdown
Collaborator

This fixes a bonehead mistake in the depth-based tapering of Leith+E (aka Leithy) backscatter. The code computes and applies the taper over the entire 2D tile simultaneously; the bonehead mistake was to put that computation inside a do loop over the elements of the tile, so that the computational cost is squared. This PR simply moves the computation and application of the taper back outside the do loop, where it should be.

Moves a global computation outside of a do loop so that it doesn't
do the global computation over and over.
@klindsay28
Copy link
Copy Markdown
Collaborator

The MOM6 code style guide at https://github.com/mom-ocean/MOM6/wiki/Code-style-guide#array-syntax disallows this type of usage of array syntax. It seems like fix the identified problem, and adhere to the style guide, by keeping the original multiplication of m_leithy where it is and introducing i,j indices to the arrays.

@iangrooms
Copy link
Copy Markdown
Collaborator Author

Thanks! I will make that change.

@iangrooms
Copy link
Copy Markdown
Collaborator Author

That will also mean I don't need the "where" statements in the leithy taper function.

@klindsay28
Copy link
Copy Markdown
Collaborator

So it looks like the original code was multiplying the entire array m_leithy by leithy_taper_function many times, instead of just once. I think this is equivalent to multiplying by leithy_taper_function**N, where N is the number of grid cells in a block. So the effective tapering is almost like a step function. The bug was not just an efficiency problem, it was a correctness problem. Please be sure to examine the effect of correcting this on solutions.

@iangrooms
Copy link
Copy Markdown
Collaborator Author

Thanks again! I'm rushing this as I approach the weekend. In fact I'm writing this from the car.

I agree about the correctness. This does not affect the 090 series of G cases which I used to tune the taper, but it does affect coupled run 236.002. Maybe that's a partial explanation for why the MOC is different in 236.002 as compared to the G case runs.

@iangrooms iangrooms marked this pull request as ready for review January 22, 2026 17:49
@alperaltuntas alperaltuntas added this to the cesm3_0_alpha08g milestone Jan 22, 2026
@alperaltuntas alperaltuntas merged commit 285fc12 into NCAR:dev/ncar Feb 11, 2026
52 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants